Method and an apparatus to disambiguate requests

ABSTRACT

A method and an apparatus to disambiguate requests are presented. In one embodiment, the method includes receiving a request for information from a user. Then data is retrieved from a back-end database in response to the request. Based on a predetermined configuration of a disambiguation system and the data retrieved, the ambiguity within the request is dynamically resolved.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Continuation of U.S. patent application Ser. No.11/701,811, filed Feb. 2, 2007, which is a Continuation-in-part of Ser.No. 11/699,899, filed Jan. 29, 2007, all of which are incorporatedherein in their entirety by this reference thereto.

TECHNICAL FIELD

The present invention generally relates to enhancing search ofinformation in an interactive voice response (IVR) system, and moreparticularly, to disambiguating search requests in an IVR system.

BACKGROUND

Speech applications, which generally refer to applications that processspeech, have undergone rapid advancement in recent years and are findingwidespread use in many different areas. One widespread use of speechapplications is in “call handling.” A common example of call handlingapplications is automated directory assistance. Automated directoryassistance is being used by businesses more and more commonly to handleincoming telephone calls requesting information. An automated directoryassistance application may receive a spoken request from a telephonecaller for information, such as a telephone number, recognize thecaller's speech to identify the requested information, and provide therequested information to the caller using recorded or synthesizedspeech. For instance, automated directory assistance may be incorporatedinto a company's telephone network to allow callers to retrievetelephone extension numbers of employees. In another example, atelephone service provider provides automated directory assistance tolook up telephone numbers requested by users. Such a system might beimplemented, for example, in a call center associated with a telephonenetwork, such as a public switched telephone network (PSTN), a voiceover Internet Protocol (VoIP) network, etc.

However, ambiguous situations sometimes arise when several entries matcha request from a caller, and thus, additional constraints from thecaller are needed to help narrow down the result. Examples of suchdisambiguation situations include selecting from a list of matchingflights in a flight reservation system, choosing a restaurant from alist of matching restaurants in a dining guide application, providingdisambiguating information to narrow down the desired listing in adirectory assistance application, etc.

Many speech applications have designed and developed customdisambiguation strategies, applicable only to a particular applicationinstance or domain. To design a custom disambiguation strategy, theentire list of possible dialog paths and dialog states has to beenumerated at design time. At runtime, an incoming request from a callerand/or data retrieved in response to the incoming request are comparedto the static list of possible dialog paths and dialog states fordetermining if disambiguation is needed. If disambiguation is needed,then a predefined disambiguation prompt is played out to the caller.However, the above approach is fraught with problems. First, it iscumbersome to pre-specify all the states since the number of allpossible dialog paths and dialog states may be prohibitively large.Further, by designing and coding a specific dialog strategy, it becomesinfeasible, if not impossible, to modify the dialog behavior laterwithout significant code modifications.

SUMMARY

The present invention includes a method and an apparatus to disambiguatesearch requests. In one embodiment, the method includes receiving arequest for information from a user. Then data is retrieved from aback-end database in response to the request. Based on a predeterminedconfiguration of a disambiguation system and the data retrieved, theambiguity within the request is dynamically resolved. The configurationmay include a set of rules and policies configurable by an integrator(also known as the administrator) of the system.

Other features of the present invention will be apparent from theaccompanying drawings and from the detailed description that follows.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and notlimitation in the figures of the accompanying drawings, in which likereferences indicate similar elements and in which:

FIG. 1 illustrates a functional diagram of one embodiment of a directoryassistance system;

FIG. 2 illustrates an architecture of one embodiment of a disambiguationengine;

FIG. 3 shows a table of exemplary disambiguation rules according to oneembodiment of the invention;

FIGS. 4A-4C illustrate some examples of disambiguation according to someembodiments of the invention;

FIG. 5 illustrates a flow diagram of one embodiment of a process todisambiguate a request for information;

FIG. 6 illustrates one embodiment of a directory assistance system; and

FIG. 7 illustrates an exemplary computing system usable to implement oneembodiment of a disambiguation system.

DETAILED DESCRIPTION

A method and an apparatus to disambiguate requests for information in aninteractive voice response (IVR) system are described. In the followingdescription, numerous specific details are set forth. However, it isunderstood that embodiments of the invention may be practiced withoutthese specific details. In other instances, well-known components,structures, and techniques have not been shown in detail in order not toobscure the understanding of this description.

In one embodiment, the method includes receiving a request forinformation from a user. Then data is retrieved from a back-end databasein response to the request. However, ambiguity may arise in some cases.Ambiguity generally refers to situations in which multiple distinctiveentries of data are found to match a single request. For example,ambiguity arises when multiple distinctive telephone numbers fordifferent departments (e.g., women's clothing, men's clothing, customerservice, home department, etc.) within a department store are found inresponse to a request for the telephone number of the department store.A configurable disambiguation system is used to dynamically resolve theambiguity.

The disambiguation system has been configured with policies and/or rulesto disambiguate requests. In general, a rule determines what the nextstep of disambiguation is based on distinctive ambiguous entries in thedata retrieved. A policy generally defines ways to apply the rules tothe data and behavior used for disambiguation. Based on theconfiguration of the disambiguation system and the data retrieved, theambiguity within the request is dynamically resolved. To dynamicallyresolve the ambiguity, prompts and/or grammar are dynamically generatedduring the course of a disambiguation dialog with the user. Using theprompts, requests for clarification are made. In response to thedisambiguation prompts, the user may clarify the request. Using thegrammar generated, response from the user is analyzed to determine ifthe data retrieved may be further refined.

By using the above configurable disambiguation system to dynamicallyresolve ambiguity, a designer of the disambiguation system does not haveto enumerate all possible disambiguation paths and states, which is ahuge task susceptible to errors. Further, the way disambiguation isperformed may be readily modified by editing the configuration files ofthe disambiguation system, thus making the disambiguation system aframework reusable for different applications.

Note that the disambiguation technique disclosed herein may be appliedto flat or hierarchical data. Further, the disambiguation techniquedisclosed herein has many different applications, such as speech-drivenautomated directory assistance, speech-driven flight reservation system,handheld-based automated directory assistance, speech-driven hotelreservation system, etc. In the following discussion, examples andfeatures of the disambiguation technique are discussed in the context ofspeech-driven automated directory assistance (DA). However, one shouldappreciate that these examples are for illustration, and are notintended to limit the scope of the appending claims.

System Overview

FIG. 1 illustrates a functional diagram of one embodiment of a directoryassistance (DA) system. The system 200 includes a disambiguation engine210 and a speech directory database 220. A user of the system 200, alsoreferred to as a caller, submits requests 201A-201E for telephonenumbers of some entities of interest. However, the requests 201A-201Emay provide different types of information to identify the entities ofinterest and the information in each request may or may not besufficient to identify a single specific entity. For instance, therequest 201A provides a business name and a street address to identifythe entity of interest, the request 201B provides only a partialbusiness name of the entity of interest, request 201C provides acomplete business name of the entity of interest, request 201D providesa city name in which the entity of interest is in, and request 201Eprovides a city name as well as a value of a caption of the entity ofinterest. The requests 201A-201E are input to the disambiguation engine210, which submits queries 203 to the speech directory database 220 toretrieve relevant data for the requests 201A-201E. For instance, thedisambiguation engine 210 extracts the business name and the streetaddress from the request 201A and fill slots of a query with theextracted business name and street address. Then the disambiguationengine 210 submits the query to the speech directory database 220 toretrieve entries having the business name and the street address.

In some embodiments, the speech directory database 220 is populated withdata from a DA listing or a set of DA listings 225 from multiple sources(e.g., a published telephone directory from a telephone company). Thedata from the DA listings 225 is arranged in a format usable by thedisambiguation engine 210. For example, data of each entry in the DAlistings 225 is extracted and stored in the corresponding columns (suchas business name, street address, department, telephone number, etc.) inthe speech directory database 220. For example, the business name of thefirst entry in the speech directory database 220 is stored in slot 221and the department of the first entry is stored in slot 222. In responseto the queries 203, matching results 205 are returned from the speechdirectory database 220 to the disambiguation engine 210.

Based on the matching results 205 and configuration of thedisambiguation engine 210, the disambiguation engine 210 determines ifdisambiguation is needed. If not, the disambiguation engine 210 returnsthe matching results 205 to the caller. Otherwise, if disambiguation isneeded, the disambiguation engine 210 performs disambiguation. Forexample, the disambiguation engine 210 may generate a question based onthe matching results 205 and configuration of the disambiguation engine210. The configuration of the disambiguation engine 210 may includerules and/or policies. More details of the configuration of thedisambiguation engine 210 are discussed below. The question generated isthen rendered to the caller, who provides a response to thedisambiguation engine 210. Based on the response, the disambiguationengine 210 may release a telephone number selected out of the matchingresults 205, generate further questions to continue the disambiguationprocess, or terminate the disambiguation process under certainconditions. More details of some embodiments of the disambiguationengine 210 and the disambiguation techniques are described below.Disambiguation Engine Architecture

FIG. 2 illustrates the architecture of a disambiguation engine (DE) in aDA system according to one embodiment of the invention. The system 100includes a DE controller 110, a view renderer 120, and a model 130,operatively coupled to each other. The DE controller 110 furtherincludes a disambiguation server 112, an ambiguity detection module 114,a policy engine 118, and a rule processor 116. The view renderer 120includes a rendering template processor 121, a prompt template processor125, and a grammar template processor 129. The model 130 includes adatabase access module 132, an object adaptation module 133, and asession frame 135. The database access and object adaptation module 132is operable to access a database 131, web service 137, and/or a localfile system 139. In some embodiments, the local file system 139 includesdocuments written in Extensible Markup Language (XML). Thedisambiguation server 112 and the rendering template processor 121 arefurther coupled to a voice browser 140.

Note that any or all of the components of the DE 100 and associatedhardware may be used in various embodiments of the present invention.However, it can be appreciated that other configurations of the DE 100may include more or fewer devices than those discussed above.

As illustrated in FIG. 1, the DE 100 adopts a model-view-controllerarchitecture, which may be used for various applications, such asweb-based applications, voice applications, etc. In general, listingrequests (e.g., Hypertext Transfer Protocol (HTTP) requests) fromcallers are passed from a client to the DE controller 110, which updatesthe model 130, and then invokes the view renderer 120, which renders aresponse to the request. The view renderer 120 uses a template-drivenmechanism, and so may be extended to different types of views (e.g.,voice, Hypertext Markup Language (HTML) documents, text, etc.). Themodel 130 includes the abstracted application-specific backend data. TheDE controller 110 is independent of the application-specific back-enddata, and therefore an interface is provided through which the data isadapted. This adapter model allows the DE 100 to be decoupled from theapplication specific data and its representation. Furthermore, the DEcontroller 110 includes the disambiguation server 112 that handles theclient requests and the other business logic that is used to manipulatethe model 130. The disambiguation server 112 may be implemented on theJava 2 Platform Enterprise Edition (J2EE) as a Servlet. To furtherillustrate the DE 100, an exemplary flow is described below.

Before receiving the first request for information, the disambiguationserver 112 loads the rule processor 116 and the associated configurationfiles, as well as sets up the connection to the data access and objectadaptation module 132. In response to user input, the voice browser 140sends a request (e.g., a HTTP request) to the disambiguation server 112.Based on the user input, the voice browser 140 passes along a list ofcurrently filled slots, as well as flags indicating which slots havealready been confirmed, with the request. In some cases, the callingapplication may have placed data into a session (e.g., a J2EE session)in the session frame 135 that is to be used by the data access module132 and object adaptation module 133. The disambiguation server 112invokes data access through a generic interface. This generic interfaceis implemented by an application-specific data access class or module.The application specific data access class or module fetches a set ofdata that satisfies the request, such as by performing a query to theback-end database 131 with the currently filled slots as the queryparameters. The data access module 132 accesses the data source (e.g.,the back-end database 131, another database via the web service 137, thelocal file system 139, etc.), and fetches the data. The data is thenmanipulated by the DE 100 through a generic data adaptation interface,the object adaptation module 133. This generic interface is implementedfor the specific application to translate the application specific datainto a generic form that is understood by the DE 100.

Note that the data is potentially ambiguous because multiple entriesmatching the request may be retrieved. The disambiguation server 112invokes the rules processor 116 to determine if the data requiresdisambiguation, and if it does, executes the pre-loaded rules on thedata from the session frame 135. The rule processor 116 then updates thesession frame 135 with the applicable rule. The controller 110determines if a confirmation or disambiguation dialog is required andredirects the voice browser 140 to the appropriate rendering template.The voice browser 140 requests the rendering template it was redirectedto. The rendering template processor 121 invokes the prompt templateprocessor 125, which utilizes the appropriate plug-in depending on thetype of markup language used by the voice browser 140 (e.g., VoiceXML).The rendering template processor 121 further invokes the grammartemplate processor 129, which utilizes the appropriate plug-in dependingon the grammar format supported by the voice browser 140. The renderingtemplate processor 121 returns the generated speech markup to the voicebrowser 140, and the confirmation or disambiguation dialog begins.

With the above introduction in mind, various components in the system100 are described in greater detail below.

Disambiguation Engine Controller

As mentioned above, the DE controller 110 includes the disambiguationserver 112 and the rule processor 116. Together, these components handleincoming requests from the voice browser 140, and invoke the necessarycomponents required to determine the next dialog state for the voicebrowser 140 to execute.

The disambiguation server 112, which may be implemented as a J2EEservlet, handles requests from the voice browser 140 and orchestratesthe use of other components in order to determine the next response todeliver to the voice browser 140. The disambiguation server 112 performsvarious operations in response to a request for information. Forexample, the disambiguation server 112 extracts data from the incomingrequest, including, for example, recognition slot names, value pairs,and confirmation flags for slots that may have already beendisambiguated and confirmed outside of the DE 100. Then thedisambiguation server 112 invokes the data access and object adaptationmodule 132 to fetch the appropriate data based upon the extracted slotvalues. Next, the disambiguation server 112 invokes the rule processor116 to attempt to match a rule based upon the configured rules and thedata retrieved by the data access and object adaptation module 132. Thedisambiguation server 112 determines if confirmation of the currentdisambiguation operation is required based upon confidences and currentconfirmation status, and invokes a confirmation dialog if necessary. Thedisambiguation server 112 further determines if additional input isrequired, or if disambiguation is complete, by invoking the ambiguitydetector 114, and redirects the voice browser 140 to the appropriaterendering template in the view renderer 120.

In addition to the disambiguation server 112, the controller 110 furtherincludes the rule processor 116. The rule processor 116 is operable toapply rules by loading a rule configuration and running a set ofambiguous data through each of the rules until a match is found or allthe rules have fired. The rule processor 116 performs various operationsto apply the rules. For instance, the rule processor 116 loadsdisambiguation rules from a configuration file, which may be written inXML. The rule processor 116 accepts ambiguous data set in slotname/value (KV) pair format. The rule processor 116 removes any datafrom the set that has been disambiguated during the last dialog turn.For slots named in the current rule being processed, the rule processor116 determines the number of unique values for each slot. If multipledistinctive values exist and disambiguation is possible, then the ruleprocessor 116 determines whether to use an open or closed promptingstrategy based on the number of distinctive slot values. The ruleprocessor 116 invokes the ambiguity detector 114 to determine if theremaining data is unambiguous, and if so, ceases disambiguating.Finally, the rule processor 116 returns the matched rule.

As discussed above, ambiguity can generally be described as the casewhen multiple distinctive entries for a given set of recognized slotsare returned in a request.

When only one entry is returned, disambiguation is deemed successful insome embodiments. However, more complex definitions of success indisambiguation may be adopted in other embodiments.

In some embodiments, the ambiguity detector 114 is implemented as aplug-in since the definition of ambiguity may change depending onvarious factors, such as the disambiguation domain, backend datastructure, and content. For example, in the DA domain, it is sometimesacceptable to return a listing that has not been completelydisambiguated if the DE 100 determines that further disambiguation islikely to be unsuccessful due to the number of listings and/or thecomplexity of the dialog. The ambiguity detector 114 provides a way forintegrators to implement custom logic that can bypass default DEprocessing. Since a call is made to the ambiguity detector 114 at theend of each dialog turn, integrators may prematurely halt execution ofthe DE 100 by having the ambiguity detector 114 tell the DE 100 thatambiguity has been resolved. By returning “true,” the ambiguity detector114 indicates to the DE 100 that disambiguation is complete and thus,the DE 100 returns control to the calling application.

Disambiguation Model

As mentioned above, the model 130 includes the data access interface andobject adaptation interface 132 modules to retrieve and manipulateapplication-specific backend data to disambiguate, as well as a sessionframe 135, which provides a session scope storage mechanism, to storeintermediate results, and data used by the rendering template processor121, the prompt template processor 125, and/or the grammar templateprocessor 129.

The DE 100 exposes an interface called DataAccessInterface through whichthe back-end data is fetched. When the DE 100 is employed in aparticular application, all methods defined by this interface areimplemented for access of data that is specific to the application.Through this pre-determined interface, the DE 100 is able to access theapplication-specific data yet remains completely independent of how thisdata is accessed or where this data comes from, e.g. Oracle database,file system, web service, etc. Since every particular application thatemploys the DE 100 may have a unique representation of the back-enddata, the DE 100 exposes an adaptation interface calledGenericDataAdapterInterface. This interface defines a set of methods toaccess particular fields of or manipulate the application-specificrepresentation of the data. For example, in order to access the field ofthe data that corresponds to the “caption” or “department” slot, theGenericDataAdapterInterface defines the method:

Public Object

getFieldForSlot(Object applicationdata, Slot slot)

The application-specific class that implements the methods defined byGenericDataAdapterInterface then provides the implementation thatretrieves the field from the data that corresponds to the “caption” or“department” slot, as in this example. This pre-determined interfaceallows the DE 100 to remain decoupled from the application-specific datamanipulation and representation.

Disambiguation View

The third component in the DE 100 is the view renderer 120. The viewrenderer 120 is responsible for generating the response in the formatthat is specific to the application, such as VoiceXML speech markup thatembodies the generated prompts and the GrammarXML (GrXML) grammar thatdefines the acceptable user input. The format of the response that isrendered by the DE 100 is defined in a set of template files that arebased on the language defined by the Apache Velocity template framework.By rendering the response through these templates, the DE controller 110is entirely decoupled from the view renderer 120 and is independent ofthe format in which the response is generated (e.g. VoiceXML, HTML,text, etc.). In some embodiments, the default implementation providesthe disambiguation dialog and confirmation dialog templates such thatVoiceXML speech mark-up is generated, and a grammar template whichgenerates GrXML grammar.

In one embodiment, the same single rendering template is used togenerate for all the various disambiguation rules. However, theconfiguration allows specification of a different template for each ruleif a particular rule is required to create a differing dialog. As such,multiple rendering templates may be used depending on the disambiguationrule and/or the data being disambiguated.

To render a question, the rendering template processor 121 performsvarious operations. For example, the rendering template processor 121determines if the applicable rule is open or closed. If the applicablerule is a closed rule, then all the possible choices are enumerated andthe caller is requested to select one of the possible choices. If theapplicable rule is an open rule, then the caller is informed thatmultiple entries are found and an open ended question is generated torequest the caller to clarify the request. The prompt template processor125 generates appropriate open or closed prompts using the promptgeneration configuration for the applicable rule. Likewise, the grammartemplate processor 129 generates appropriate open or closed grammar forapplicable rule. The default rendering templates generate appropriatespeech markup for the voice browser 140, and a set of slots that are thesubject of disambiguation for the applicable rule. The renderingtemplate processor 121 may store spoken utterances for voice store andforward (VSF). Since disambiguation utterances are required for VSF inthe automated directory assistance application, the DE templates for thedirectory assistance application gather and store each disambiguationutterance spoken by the caller. For rules that may fire more than once(e.g., captions in DA), the DE 100 attempts to store the most salientutterance (such as the first or the last utterance) and to remove anyresults that do not match the request upon further disambiguation.

In some embodiments, the default implementation generates VoiceXMLspeech markupto create a dialog with the caller. The prompts that areused to provide the information to the caller are generated based on theprompt configuration for the particular disambiguation rule (promptconfiguration described below). For example, depending on the promptconfiguration for a rule specifying disambiguation of the location of adirectory assistance listing (both city and street simultaneously), thefollowing dialog may be generated based on the ambiguous listings thatare retrieved from the database:

-   DE: “Ok, I found 3 locations for that request. One on Prince Street    in Montreal, one on King street, and one other. Which one would you    like?”-   Caller: “The one in Montreal”

DE: “Ok, to confirm, that was Prince Street in Montreal, Quebec right?”

-   Caller: “Yes”

In the above example, the DE 100 not only confirms Prince Street, butalso confirms the previously gathered, but as yet unconfirmedinformation, namely, the province of Quebec. In addition to the prompttemplate processor 125, the view renderer 120 also includes the grammartemplate processor 129. The grammar template processor automaticallygenerates the different possible user inputs for the slots defined bythe disambiguation from the set of ambiguous data for the slots. Inaddition, the grammar generation provides a configuration mechanism todefine additional optional phrases that are then added to the generatedgrammar for a particular slot. For example, when disambiguating thecaption or department of a set of directory assistance listings, thecaller may say the word “department” in addition to the providedchoices. The word “department” could thus be added to the configurationfor the caption slot, thus accepting all user responses that may or maynot include this word. The grammar configuration also includes amechanism to force words or phrases commonly found in the data to becomeoptional in the grammar, and thus not required to be said by the caller.For example, a lot of directory assistance listings may include the word“incorporated” in the data, and yet the caller will unlikely not saythis word as part of his response to a disambiguation dialog. As such,the word “incorporated” can be configured to be optional.

Configuring the Disambiguation Engine

In some embodiments, the DE 100 relies upon two configuration files: 1)disambiguation-configuration.xml, which contains the disambiguationrules used by the rule processor 116, and 2)disambiguation-prompt-configuration.xml, which contains promptgeneration specification for each of the disambiguation rules and isused by the prompt template processor 125 to dynamically generateprompts. The dialog generator dynamically generates the prompts atruntime based on the rule's prompt configuration and on the ambiguousdata that is currently being disambiguated.

Disambiguation rules determine what the next step of dialog is based ondistinctive ambiguous item(s) in the data retrieved. These rules areconfigurable and may result in different behavior depending on the ruleorder because the rules are fired in the order that the rules appear inthe rule configuration file. The rules handle multiple slots, and/orcombinations of ambiguous data. When a rule is found to match theambiguous data, the DE controller invokes this rule and automaticallygenerates a disambiguation dialog, which includes prompts and grammar.More details of prompt and grammar generation are discussed below.

An application upon which the DE 100 is applied may have different typesof data, and each data type may have a specific set of disambiguationrules. As such, the rules configuration allows specification of adifferent set of rules for each of the data types of the application.For example, in the directory assistance application, disambiguation isperformed on listings data (datatype=“listing”), cities/localities(datatype=“locality”), and listing names (datatype=“listing-name”). Eachof these different data types is represented by a different class orconstruct, and the application-specific data access and data adaptationmodules must take into consideration the data type being disambiguatedto fetch and adapt the back-end data accordingly. To configuredisambiguation rules per data type, one or more <rule> elements areadded under <disambiguation-rules> in disambiguation-configuration.xmlaccording to some embodiments of the invention. An exemplary rule isshown below:

TABLE-US-00001 <disambiguation-rules datatype=“listing” slotlist=“namecity state caption street”> <rule name=“city-state-closed” type=“closed”threshold= “4” template=“disambiguation-template.vm”confirmation-template= “disambiguation-confirmation-template.vm”confirmation-threshold= “50”> <slot namelist=“city state”/> <properties><property name= “max-error” value=“3”/> </properties> </rule>

The top-level disambiguation-rules XML element defines that all therules embodied by this element are application to the “listing”datatype. The first example rule shown above, defines a rule named“city-state-closed” with attributes: type, threshold, template,confirmation-template, and confirmation-threshold. The name attribute isthe name of the rule and is used to trace the order of execution of therule, and can be any arbitrary value selected by the integrator. Theattribute type is one of “open” or “closed” and defines whether thisrule will result in an open-ended disambiguation dialog or a closeddisambiguation dialog, respectively. The threshold attribute defines themaximum number of unique items there must be in order for a closeddisambiguation dialog to occur. The template and confirmation-templateattributes defined the disambiguation dialog template and theconfirmation dialog template respectively. The confirmation-thresholdattribute defines the confidence score threshold, over whichconfirmation may be skipped. If the recognition confidence score duringa disambiguation dialog is less than this threshold, then a confirmationdialog is invoked.

In some embodiments, the only sub-element allowed within a <rule>is a<slot>tag of the following form:

-   <slot namelist=“city state”/> The slot tag defines the slots or    fields of the data that must be ambiguous in order for this rule to    apply. In the example above, more than one slot is specified by    separating each of the slot's names by a space in the value of the    namelist attribute. If some slot names and values are collected    outside of the DE 100, but are necessary to the disambiguation    dialog, then the name strings passed on the query string has to    match exactly the contents of the configuration file in order to    allow the DE 100 to access such slot names and values. Further,    confirmation flags are in the form of <slot name> plus “Confirmed”    in some embodiments, e.g., cityConfirmed.

Configuring disambiguation-prompt-configuration.xml is similar toconfiguring disambiguation-configuration.xml in that there is typicallyone prompt generation rule for every disambiguation rule. The promptconfiguration is kept separate from the rule configuration in order tokeep the human readable configuration files easy to understand andmanipulate, and to promote separation of concerns and modularity.Keeping the two configuration files distinct allows the promptconfiguration to be updated independently without the risk of affectingthe rule processor 116.

If a disambiguation rule fires, then a matching prompt configurationrule is extracted for generation of the corresponding prompt in thedisambiguation dialog. To configure prompt generation rules, one or more<prompt-configuration> elements are added under the<disambiguation-prompt-configuration> parent. An exemplary promptgeneration rule is shown below:

TABLE-US-00002 <prompt-configuration rule-name=“city-state-closed”> <!--Disambiguation prompting --> <disambiguation> <promptcondition=“rule-initial” name=“city-state-closed-init_a.wav” text=“Ifound”/> <prompt condition=“rule-follow-up”name=“city-state-closed-follow-up_a.wav” text=“Ok. Now, I found”/><prompt condition=“same-rule-follow-up”name=“city-state-closed-same-follow-up_a.wav” text=“This time I found”/><itemcount/> <prompt name=“city-state-closed-init_b.wav”text=“locations:”/> <enumerate connector-prompt-name=“one.wav”connector-prompt- text=“one” last-connector-prompt-name=“and.wav”last-connector-prompt-text=“and”> <slot namelist=“city state”/></enumerate> <prompt name=“city-state-closed-init_c.wav” text=“Which onedid you want?”/> <!-- Previous result is part of the disambiguation --><previous-result> <prompt name=“prev-init.wav” text=“And I have onethat's just listed as ”/> <enumerate> <slot namelist=“name captionstreet city state ”/> </enumerate> </previous-result> </disambiguation><!-- Confirmation prompting --> <confirmation> <promptname=“disambig-conf-3-init_a.wav” text=“To confirm. That was ”/><enumerate> <slot namelist=“name caption street city state”/></enumerate> <prompt name=“disambig-conf-3-init_b.wav” text=“Right?”/></confirmation> </prompt- configuration>

The rule-name attribute of the prompt-configuration element must match adisambiguation rule defined in the rules configuration file. Eachdisambiguation rule must have a corresponding prompt configuration inthe prompt configuration file.

The prompt configuration allows for distinct prompting for thedisambiguation dialog (embodied within the <disambiguation> element) andfor the confirmation dialog (embodied within the <confirmation>element). Within the <disambiguation> or <confirmation> elements, thefollowing elements are allowed for different purposes: the <prompt>element is used to define a prompt audio file and the back-off text(that may be rendered with a text-to-speech engine), the <enumerate>element which defines the enumeration of the particular fields of thedata, or the <itemcount> element which defines the playback of thenumber of unique ambiguous items being disambiguated during thisparticular disambiguation dialog. For example, the <prompt> element isstatically defined, and contains the audio file prompt name, and thetextual representation of the prompt. For example, an exemplary <prompt>element is shown below:

-   <prompt name=“city-state-closed-init_a.wav” text=“I found”>

A <slot> element inside an <enumerate> element defines dynamic contentto be rendered via text-to-speech (TTS) when the prompt is rendered. The<itemcount> element is often used in conjunction with the <enumerate>element to list the ambiguous choices to caller, in order to render aprompt of the form “I found 3 Starbucks locations for that request.Which one do you want?”

In some embodiments, a <previous-result> element is provided, whichcorresponds to a feature of the DE 100 that allows a selected item to becollapsed during the previous dialog turn into the next interaction.Thus, the caller is provided with the option of halting furtherdisambiguation. For example, if the caller finds that none of thecurrent disambiguation choices are as good as the one the callerselected during the last dialog turn, then the caller may select theprevious result, and exit disambiguation. The <previous-result> elementprovides the prompt that should prefix the collapsed previous selection.

A sample dialog generated by a <previous-result> element is shown below,in which the previous result is the listing information for New YorkTimes:

-   Caller: “New York Times”

System: “I found 3 sublistings. One for circulation, one forclassifieds, and one for fax lines, or you can still get the listinginformation for New York Times. Which one do you want?” Caller: “Justgive me the number for the New York Times” System: “Okay, the number is. . . . ”

More examples of disambiguation rules are shown in the table illustratedin FIG. 3. Each of the rules in FIG. 3 has an open/closed threshold. Ifthe number of entries retrieved in response to a request is above theopen/closed threshold, an open disambiguation prompt associated with therule is rendered. Otherwise, a closed disambiguation prompt associatedwith the rule is rendered. In addition, some of the rules may beassociated with a confirmation prompt to confirm an entry selected fromthe entries retrieved is the one the user wants.

Since the DE 100 is configurable, a designer of the DA system does nothave to enumerate all possible disambiguation paths and states, which isa huge task susceptible to errors. Further, the way disambiguation isperformed may be readily modified by editing one or more theconfiguration files of the DE 100, thus making the DE 100 a frameworkreusable for different applications.

Degree of Disambiguation

In some embodiments of a DA system, “success” is defined as releasing anumber for a listing. After listening to lots of calls in existing DAdeployments and in calling human operators for directory assistancerequests, it became clear that neither these applications nor humanoperators are very conscientious about providing the right number. Theyare often too quick to release “a” number as opposed to really trying torelease the right number. At the other extreme, a disambiguation enginemay try too long even if it is unclear whether going deeper into thedata is necessarily better than releasing a number that exists at somepoint.

To work well, a good balance between the somewhat contradictory goals ofachieving high success rates and providing a high degree of usabilityhas to be achieved. Either one alone would not produce acceptableresult. In other words, the DE 100 needs to have a way of determiningthe optimal time to give up and hand control back to the voice browser140 for the overall DA system. In some embodiments, this determinationis based on two factors—the length of the disambiguation dialog that hasbeen completed so far and an estimate of the degree of difficulty of thedisambiguation problem ahead.

In some embodiments, the DE 100 uses two measures to determine when tostop trying for hierarchical databases. The first measure is aconfigurable threshold, which specifies how deep in the hierarchy the DE100 should go before the DE 100 should give up. This threshold is calleddisambiguation-level-threshold. Another measure is the estimation of thedegree of difficulty of the remaining dialog, which is based on anestimate of the degree of difficulty of the grammars for the choicesbeing provided. When both thresholds are exceeded, the DE 100 stopsdisambiguating and releases a number to the caller. An integrator of theDA system may set and adjust these thresholds based on experience and/orstatistics collected from the DA system.

Dialog Generation

In addition to observing the thresholds discussed above, the DE 100 mayfollow various overriding rules. In one embodiment, an overriding ruleprovides that, at any point in the disambiguation, if there is only onenode with an associated phone number left and this node has only onechild, then the number at that node is released. Further disambiguationmay not be performed.

In some embodiments, the data is organized hierarchically such thatthere are multiple levels of data and there are one or more nodes oneach level. For example, the data may be organized into a tree graph.Note that in a DA system, a node may or may not have an associatedtelephone number. The DE 100 reviews the data one level at a time duringdisambiguation. If the DE 100 has resolved down to only one node thatdoes not have an associated telephone number on a particular level, butthis node has one child with a number on another level, then the DE 100may release the number of the child node without asking furtherquestions.

In some embodiments, some listings may have very long and complex namesthat may be difficult to recognize properly. So, the DE 100 estimatesthe degree of difficulty of the future dialog by calculating anAdjustedWordLength of the grammar choices at any point. TheAdjustedWordLength of a grammar choice refers to the number of wordsthat have to be input for that choice to match. One overriding ruleprovides that, if the engine ends up with only one node with anassociated phone number and more than one of its children haveAdjustedWordLengths greater than a predetermined threshold, then thenumber at that node is released.

During disambiguation, the parent of the current node(s) may be offeredin addition to the other choices. In some embodiments, if the DE 100ends up with a single listing and decides to continue with furtherdisambiguation (as determined based on other rules) and if the parenthas an associated phone number, then the parent is also offered alongwith the other choices.

Prompt Generation

In some embodiments, some special prompt rules are added to make theprompts more natural and less monotonous. The prompt for every rule isgenerated by using one of several configurable prompt segments, such astransitional phrases (e.g., “Okay”), to be used in different situations,such as: A) when this is the first rule to match, B) when this is thesecond (or greater) time the same rule matches in succession, and C)when this rule matches after some other rule has matched before it.Using this prompt strategy, the dialog sounds more natural as shown bythe following exemplary disambiguation dialog:

-   System: “I found it on three streets: Main street, Floyd road, and    Willow bend. Which one is it?” [Case A] User: uh, yes it's on Floyd    road. System: “Ok, now I found 2 departments or sublistings: card    member inquiries and line of credit inquiries. Which would you    like?” [Case B] User: card member inquiries System: “This time, I    found 3 more: apply for a card, lost or stolen card, or billing    information. Which would you like?” [Case C]

Without the above approach, the dialog would have been much moremonotonous. The above approach is consistent with generally accepteddialog principles that the system has to keep track of the current stateof the dialog and has to insert appropriate discourse markers to makethe dialog flow more naturally.

Grammar Generation

In general, speech from the caller may be recognized by comparing thecaller's utterances to a set of “grammars.” In this context, a grammaris defined as a set of one or more words and/or phrases (“expressions”)that a caller is expected or required to utter in response to acorresponding prompt, and the logical relationships between suchexpressions. The logical relationships include the expected or requiredtemporal relationships between expressions, whether particularexpressions are mandatory, optional, alternatives, etc. Defining andgenerating the grammars may be time-consuming and difficult, thus, thegrammar template processor 129 in the DE 100 uses grammar templates togenerate grammar.

The DE 100 uses the grammar template processor 129 to automaticallygenerate grammars used to recognize the caller's utterance during thedisambiguation dialog. The grammar generated returns at least one slotin order to avoid ambiguity within the grammar. To ensure the grammargenerated returns at least one slot, the grammar template processor 129checks to make sure that each slot that can be returned has at least oneparse or possible phrase associated with the slot. Further, the grammartemplate processor 129 may also check to make sure that each phraseusable to parse the grammar returns at least one slot.

In some embodiments, a set of predetermined words in the choices beingoffered are made optional depending on the type of slot that this choicebelongs to. For example, for company names, words like “limited”,“incorporated”, “company”, etc., are made optional since the caller maynot always provide the complete name. Likewise, for street names, wordslike “street”, “avenue”, “highway”, etc. are made optional.

Policy

Policies define ways to apply business rules to the data and behaviorused for disambiguation. There are multiple different types ofdisambiguation policies, such as release policies, data access policies,data filter policies, and rule selection policies. Default policies areused when no other policies are defined or if a defined policy fails.The different types of policies are exposed as interfaces by the DE 100and policies specific to the application must implement thecorresponding interface and abide by the contract defined by the DEinterface. Some exemplary policies are discussed in details below toillustrate the concept.

Release policies are criteria that if met, allow the DE 100 toimmediately select a piece of unambiguous data to be “released” withoutexecuting the disambiguation rules and behavior. For example, a “ReleaseMain” release policy might enable the following business rule: If onlyone main number has been specified for the search space (local book,fallback book, or generalized search across all books), then releasethat number without disambiguating.

Data access policies allow the DE 100 to bypass the default data accessmethods based on some predetermined criteria. For example, a defaultdata access policy for DA may include some rules that define when tostop the disambiguation process. In some embodiments, a “FrequentlyRequested Listing (FRL)” data access policy might enable the followingbusiness rule: For a listing recognized in a “What Listing” context, inwhich the first question posed to the caller is “What is the listingname?”, only those sublistings flagged as “FRL” are candidates fordisambiguation.

Data filter policies are applied following the data access policies. Ingeneral, data filter policies include predetermined criteria that allowthe DE 100 to filter the data to be included for disambiguation based onthe criteria. For example, a “Book ID” data filter policy might enablethe following business rule: Given that 80% of enquiries are within acaller's local book, the listings query for FRLs may be restricted toonly those within the caller's local book. If no match is found withinthe local book, then a secondary book that has been specified for thatlocal book is searched. If there is still no match, then an open queryis sent to all books.

Rule selection policies allow a user to customize how rules are selectedbased on certain criteria. In some embodiments, the DE 100 goes throughall possible rules that could match the disambiguation data at hand andprovides a list to the rule selection policy to make the final ruleselection. If no rule selection policy is defined or if it fails, thedefault rule selection policy of choosing the first matching rule isused. For example, a “Caption Empty” Rule Selection policy attempts toprevent a caption question being asked when multiple rows exist in whichthe caption slot is empty. Where the caption field contains data that itshouldn't, such as locality data, this policy will act to make sure thata caption question is not asked inappropriately.

In some embodiments, the policy engine 118 applies the policies duringdisambiguation. In order to include these policies or additional rules,an interface for each type of policy is implemented. The policy is thenactivated via a policy configuration file. In this policy configurationfile, policies are first defined by being given a name within the scopeof the configuration file and mapped to the programmed class theimplements the interface. An example of a policy definition is shownbelow:

TABLE-US-00003 <policy-definitionname=“pre-disambiguation-main-number-release” type=“release” java-class=“com.nuance.ndaa.disambiguation.policy.MainNumberReleasePolicy”/>

The type attribute for this policy definition specifies that this is arelease type policy, and therefore the interface pertaining to releasepolicies (i.e., ReleasePolicy) has to be implemented by the Java classthat is defined by the java-class attribute. In this case, the fullyqualified class name is“com.nuance.ndaa.disambiguation.policy.MainNumberReleasePolicy.” Oncethe policy is defined, the policy can be activated in the policyconfiguration file as part of a group of policies. An example of this isshown below:

TABLE-US-00004 <policy-group name=“pre-disambiguation-policies”> <policyname=“pre-disambiguation-main-number-release”/> </policy-group>All policies within a policy-group are applied in order for the entirepolicy group to apply. When multiple policy groups are defined in thepolicy configuration, only the first policy group encountered that takeseffect in its entirety will be executed, i.e., all the policies withinthe group activate successfully. In other words, either all policies areapplied successfully or none is applied according to some embodiments ofthe invention.

EXAMPLES OF DISAMBIGUATION

FIGS. 4A-4C illustrate some examples of disambiguation according to someembodiments of the invention. These examples are in the context ofdirectory assistance. However, as explained above, the disambiguationtechnique disclosed herein is not limited to directory assistanceapplications.

Referring to FIG. 4A, a caller submits a request 401 for the number forSafeway. In response to the request 401, the DA disambiguation engine410 searches for the number for Safeway in the listing database 420. Asshown in FIG. 4A, the listing database 420 contains multiple entries forSafeway at different streets with different captions. The DAdisambiguation engine 410 applies a closed street disambiguation rule toinvoke a dialog by asking question 403, namely, “I found threelocations--one on St. Joseph's, one on Stoneridge, and one on SantaRita. Which would you like?” Then the caller submitted a response 405,namely, “The one on Santa Rita.” Since there are multiple entries forthe Safeway on Santa Rita, the ambiguity has not been resolved yet. TheDA disambiguation engine 410 applies a closed caption disambiguationrule to further clarify the request. Specifically, the DA disambiguationengine 410 asks another question 407, “I have three sub-listings: onefor pharmacy, one for bakery, and one for customer service. Which onewould you like?” In response, the caller submits another response 408,namely, “Bakery.” Based on the response 408, the DA disambiguationengine 410 narrows down the entries retrieved to only one and returnsthe one entry by rendering the statement 409: “Okay, the number is . . .. ”

FIG. 4B illustrates another example of disambiguation according to oneembodiment of the invention. A caller submits a request 431 for thenumber for Safeway. In response to the request 431, the DAdisambiguation engine 440 searches for the number for Safeway in thelisting database 445. As shown in FIG. 4B, the listing database 445contains multiple entries for Safeway at different streets withdifferent captions. The DA disambiguation engine 440 applies a closeddisambiguation rule that combines both streets and captions to invoke adialog by asking question 433, namely, “For Safeway, I found thefollowing listings—the head office, one on St. Josephs Street, and onefor customer service on Stoneridge. Which would you like?” Then thecaller submits a response 435, namely, “I want Customer Service.” Basedon the response 435, the DA disambiguation engine 440 narrows down theentries retrieved to only one and returns the one entry by rendering thestatement 437: “Okay for Customer Service, the number is . . . . ”

FIG. 4C illustrates another example of disambiguation according to oneembodiment of the invention. A caller submits a request 451 for thenumber for Safeway. In response to the request 451, the DAdisambiguation engine 460 searches for the number for Safeway in thelisting database 465. As shown in FIG. 4B, the listing database 445contains multiple entries for Safeway at different streets withdifferent captions. Based on a predetermined policy, the DAdisambiguation engine 460 applies a filter value 470 for BOOK-ID customfield to narrow down the entries to those with a BOOK-ID entry equal toCA.sub.—90011. Then the DA disambiguation engine 460 generates a prompt453 according to a caption-closed disambiguation rule. The prompt 453 is“I found three departments: one for pharmacy, one for bakery, and onefor customer service. Which would you like?” The caller then submits aresponse 455, which is “For customer service.” Thus, the DAdisambiguation engine 460 releases the corresponding number to thecaller at 457.

Process to Disambiguate Requests

FIG. 5 illustrates a flow diagram of one embodiment of a process todisambiguate a request for information. The process is performed byprocessing logic of a disambiguation engine that comprises hardware(e.g., circuitry, dedicated logic, etc.), software (such as is run on ageneral-purpose computer system or a dedicated machine), firmware, or acombination of any of the above.

Referring to FIG. 5, processing logic receives a request for informationfrom a user (processing block 510). In response to the request,processing logic retrieves data from a listing database (processingblock 515). Then processing logic applies a configuration of thedisambiguation engine to the data retrieved (processing block 520). Theconfiguration may include a set of rules and/or policies.

At processing block 525, processing logic determines if the request isambiguous based on the data retrieved. As discussed above, the requestis considered ambiguous if the data retrieved includes multipledifferent entries (e.g., multiple telephone numbers for differentdepartments within a store are retrieved in response to a request for atelephone number for the store). If not, then processing logic outputsthe data retrieved (processing block 529). Otherwise, processing logicchecks if any exit condition has been met (processing block 530). Forinstance, an exit condition may be defined by one policy to be thenumber of prompts rendered has exceeded a predefined threshold value. Ifan exit condition has been met, then processing logic may output anerror message (processing block 532). Alternatively, processing logicmay take other appropriate actions according to the policies in theconfiguration of the disambiguation engine, such as directing the userto a human operator. If no exit condition has been met, processing logictransitions to processing block 535.

At processing block 535, processing logic checks if any filter has beenprovided by the policies in the configuration of the disambiguationengine. If there is a filter, then processing logic applies the filterto the data retrieved to refine the data (processing block 538) and thentransitions to block 540. Otherwise, processing logic transitions toblock 540.

At processing block 540, processing logic checks if any question is tobe rendered according to the rules in the configuration of thedisambiguation engine. If there is no question to be rendered accordingto the rules, then processing logic transitions back to processing block520 to repeat the operations on the current set of data.

If there is a question, then processing logic renders the question(processing block 543). Next, processing logic waits for a response fromthe user (processing block 545). Processing logic checks if a responseis received at processing block 547 and remains in processing block 547until a response is received. When a response is received, processinglogic selects a portion of the data based on the response (processingblock 550). Then processing logic returns to block 520 to repeat theoperations on the remaining data. Details of some examples of thedisambiguation process and some embodiments of the disambiguation enginehave been discussed above.

FIG. 6 illustrates one embodiment of a directory assistance system. Thesystem 600 includes an audio front end 620, an automatic speechrecognition engine 630, a grammar database 635, a text-to-speechconverter 640, a disambiguation engine 650, and a listing database 660.A user of the system 600 makes a call to the system 600 using atelephone 610, which is communicatively coupled to the audio front end620 via a communication network 610. The communication network 610 mayinclude a PSTN, a VoIP network, etc. The audio front end 620 routesspeech of the user to the automatic speech recognition engine 630, whichanalyzes the speech of the user and recognize the request submitted bythe user in the speech. The speech recognition engine 630 then sends therequest to the disambiguation engine 650.

Based on the request, the disambiguation engine 650 then submits a queryto the listing database 660 to retrieve data from the database 660 thatsatisfy the request. Based on the data retrieved and configuration ofthe disambiguation engine 650, the disambiguation engine 650 determinesif disambiguation has to be performed. If so, the disambiguation engine650 performs disambiguation. The disambiguation engine 650 applies rulesand policies in the configuration to the data retrieved and dynamicallygenerates prompts and grammar to request clarification from the user.The prompts 652 generated are sent to the text-to-speech converter 640,which converts the prompts 652 to audio data. The audio data is sent tothe telephone 610 via the communication network 615 to be played out tothe user. The grammar 654 generated is sent to the grammar database 635so that the automatic speech recognition engine 630 is able to retrievethe grammar 654 from the grammar database 635. The automatic speechrecognition engine 630 uses the grammar 654 to recognize a response tothe prompt 652 from the user. Details of some embodiments of thedisambiguation engine 650 and the process to disambiguate requests havebeen discussed above.

FIG. 7 illustrates an example of a computer system in which theaforementioned components and techniques can be implemented. It will berecognized that many variations upon the illustrated system can be usedto implement these components and techniques. The illustrated computersystem includes a central processing unit (CPU) 71 (e.g., amicroprocessor), read-only memory (ROM) 72, random access memory (RAM)73, and a mass storage device 74, each coupled to a bus system 82. Thebus system 82 may include one or more physical buses coupled to eachother through one or more bridges, controllers and/or adapters. Forexample, the bus system 82 may include a “system bus” coupled to one ormore peripheral buses, such as a peripheral component interconnect (PCI)bus or the like. Also coupled to the bus system are a telephonyinterface 75, and audio subsystem that includes a microphone 76 and aspeaker 77, a pointing device 78, a keyboard 79, a display device 80,and a data communication device 81.

The mass storage device 74 may include any suitable device for storinglarge volumes of data, such as a magnetic disk or tape, magneto-optical(MO) storage device, flash memory, or any of various types of DigitalVersatile Disk (DVD) or compact disk (CD) storage. The telephonyinterface 75 provides the computer system with a telephone connection toa remote caller via a telephone network, which may include a publicswitched telephone network (PSTN), a voice over Internet Protocol (VoIP)network, etc. The telephony interface 75 may also include equipment fordigitizing and ends pointing speech received over the telephoneconnection, to condition the input speech for processing by the speechrecognizer. The microphone 76 and speaker 77 may be components of atelephone I/O device (i.e., handset or headset), such as illustrated inFIG. 1 and FIG. 3, to allow a user of the computer system (e.g., thedirectory assistance operator) to speak with the remote caller. Thepointing device 78 may be any suitable device for enabling a user toposition a cursor or pointer on the display device 17, such as a mouse,trackball, touchpad, touch-sensitive display screen, or the like. Thedisplay device 80 may be any device suitable for displayingalphanumeric, graphical and/or video data to a user, such as a cathoderay tube (CRT), a liquid crystal display (LCD), or the like. The datacommunication device 81 may be any device suitable for enabling thecomputer system to communicate data with a remote processing system overcommunication link 83, such as a conventional telephone modem, a cablemodem, an Integrated Services Digital Network (ISDN) adapter, a DigitalSubscriber Line (xDSL) adapter, an Ethernet adapter, or the like.

Some portions of the preceding detailed description are presented interms of algorithms and symbolic representations of operations on databits within a computer memory. These algorithmic descriptions andrepresentations are the tools used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of operations leading to adesired result. The operations are those requiring physicalmanipulations of physical quantities. Usually, though not necessarily,these quantities take the form of electrical or magnetic signals capableof being stored, transferred, combined, compared, and otherwisemanipulated. It has proven convenient at times, principally for reasonsof common usage, to refer to these signals as bits, values, elements,symbols, characters, terms, numbers, or the like.

It should be kept in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the above discussion, itis appreciated that throughout the description, discussions utilizingterms such as “processing” or “computing” or “calculating” or“determining” or “displaying” or the like, refer to the action andprocesses of a computer system, or similar electronic computing device,that manipulates and transforms data represented as physical(electronic) quantities within the computer system's registers andmemories into other data similarly represented as physical quantitieswithin the computer system memories or registers or other suchinformation storage, transmission or display devices.

The present invention also relates to an apparatus for performing theoperations described herein. This apparatus may be specially constructedfor the required purpose, or it may comprise a general-purpose computerselectively activated or reconfigured by a computer program stored inthe computer. Such a computer program may be stored in amachine-accessible medium, also referred to as a computer-readablemedium, such as, but is not limited to, any type of disk includingfloppy disks, optical disks, CD-ROMs, and magnetic-optical disks,read-only memories (ROMs), random access memories (RAMs), EPROMs,EEPROMs, magnetic or optical cards, or any type of media suitable forstoring electronic instructions, and each coupled to a computer systembus.

The processes and displays presented herein are not inherently relatedto any particular computer or other apparatus. Various general-purposesystems may be used with programs in accordance with the teachingsherein, or it may prove convenient to construct a more specializedapparatus to perform the operations described. The required structurefor a variety of these systems will be evident from the descriptionbelow. In addition, the present invention is not described withreference to any particular programming language. It will be appreciatedthat a variety of programming languages may be used to implement theteachings of the invention as described herein.

The foregoing discussion merely describes some exemplary embodiments ofthe present invention. One skilled in the art will readily recognizefrom such discussion, the accompanying drawings and the claims thatvarious modifications can be made without departing from the spirit andscope of the invention.

1. A computer-implemented method comprising: receiving a request forinformation from a user; retrieving data from a database within a systemin response to the request; and dynamically resolving ambiguity withinthe request based on a predetermined configuration of the system and thedata retrieved, wherein the configuration comprises a policy andresolving ambiguity within the request comprises: applying the policy tothe retrieved data.
 2. The method of claim 1, wherein the configurationcomprises a rule and resolving ambiguity within the request comprises:generating a prompt based on the data retrieved and the rule at runtime;and rendering the prompt to the user.
 3. The method of claim 2, whereinresolving ambiguity within the request further comprises: receiving aresponse to the prompt from the user; generating a grammar using asecond predefined template; recognizing the response using the grammar;selecting a portion of the data retrieved based on the response; andgenerating a second prompt based on at least one of the portion of thedata retrieved, the response, and a second rule within the configurationif the ambiguity remains.
 4. The method of claim 2, wherein the promptis an open-ended question if the data retrieved includes a number ofentries exceeding a predefined threshold.
 5. The method of claim 2,wherein the prompt is a close-ended question if the data retrievedincludes a number of entries below a predefined threshold.
 6. The methodof claim 1, wherein the policy includes a data filter policy andapplying the policy to the retrieved data comprises filtering theretrieved data using a criterion specified in the data filter policy. 7.The method of claim 1, further comprising: rendering an error message ifthe ambiguity is not resolved under a predefined condition according tothe configuration of the system.
 8. An apparatus comprising: a userinterface to allow an integrator of a directory assistance system todefine a configuration of the directory assistance system; and adisambiguation engine operatively coupled to the user interface todynamically resolve ambiguity within a user request for informationaccording to the configuration of the directory assistance system,wherein the configuration includes a data filter policy and thedisambiguation engine is operable to filter data retrieved in responseto the user request based on the policy..
 9. The apparatus of claim 8,wherein the disambiguation engine comprises: a prompt template processorto generate the prompt using a first predefined template.
 10. Theapparatus of claim 9, further comprising: a voice browser to aurallypresent the prompt to a user.
 11. The apparatus of claim 10, furthercomprising: a second user interface to receive a response from the user;and a grammar template processor to generate a grammar using a secondpredefined template used by the disambiguation engine to recognize theresponse.
 12. The apparatus of claim 8, wherein the user interfacecomprises a first user interface control to allow the integrator toselect a policy out of a plurality of predefined policies.
 13. Theapparatus of claim 8, wherein the user interface comprises a second userinterface control to allow the integrator to modify the configuration.14. A system comprising: a database; and a directory assistance systemoperatively coupled to the database, the directory assistance systemcomprising: an input module to receive a request for information from auser; a database access module to retrieve data from the database inresponse to the request; and a configurable disambiguation engine todynamically resolve ambiguity within the request based, on apredetermined configuration of the directory assistance system and thedata retrieved, wherein the configuration comprises a policy and thedisambiguation engine is operable to filter the data retrieved accordingto the policy.
 15. The directory assistance system of claim 14, whereinthe disambiguation engine is operable to select a portion of the dataretrieved based on a response to the first prompt from the user.
 16. Thedirectory assistance system of claim 14, wherein the disambiguationengine is operable to generate a second prompt based on at least one ofthe response to the first prompt, the portion of the data retrieved, anda second rule within the configuration if the ambiguity remains.
 17. Thedirectory assistance system of claim 14, further comprising: a voicebrowser to aurally present the first prompt to the user.
 18. Amachine-accessible medium that stores instructions which, if executed bya processor, will cause the processor to perform operations comprising:creating a first user interface to allow an integrator of a directoryassistance system to define a configuration of the directory assistancesystem, wherein ambiguity within a request for information submitted tothe directory assistance system is dynamically resolved based on theconfiguration and data retrieved in response to the request, wherein theconfiguration comprises at least one of a policy and a rule; and storingthe configuration in a configuration database.
 19. Themachine-accessible medium of claim 18, wherein the operations furthercomprise: creating a second user interface to allow the integrator tomodify the configuration.
 20. The machine-accessible medium of claim 18,wherein the first user interface comprises: creating a user interfacecontrol to allow the integrator to select a policy out of a plurality ofpredefined policies.